coverage: 99.192% (+0.01%) from 99.181% — users/alexpeck/lfuevents10 into main

Analysis performed by Claude, data shows code size in bytes:

Update path (TryUpdate → EventInliner.OnUpdatedEvent)

Maintenance path (DoMaintenance → Evict → EventInliner.OnRemovedEvent)

Assembly evidence

In EventPolicy Evict (and OnWrite):

mov  rcx, offset MT_BitFaster.Caching.ItemRemovedEventArgs<Int32, Int32>
call CORINFO_HELP_NEWSFAST                ; allocate args
...
call qword ptr [7FFC...]                  ; EventPolicy.OnItemRemoved(Int32, Int32, ItemRemovedReason)
call qword ptr [r14+18]                   ; invoke delegate

In NoEventPolicy Evict (and OnWrite): zero matches for ItemRemovedEventArgs, OnItemRemoved, or eventPolicy field loads. The epilogue goes straight from evictedCount++ to ret.

Verdict

EventInliner.IsEnabled = typeof(E) == typeof(EventPolicy<K,V>) is folded as a JIT-time constant per generic instantiation, eliminating the event branch and everything inside it: oldValue capture, delegate field loads, null check, args allocation, invocation.

What causes the layout difference to increase code size?

The JIT compiles ConcurrentLfuCore<...EventPolicy> and ConcurrentLfuCore<...NoEventPolicy> as two separate methods
(struct generics → distinct codegen, no canonicalization). Even when the source is identical and no instructions are
added/removed, the emitted byte count can drift by tens of bytes from second-order effects:

1. Branch encoding. x86 has jmp short (2 bytes, ±127B reach) vs jmp near (5 bytes). When the surrounding code shrinks
   because events were elided, some forward jumps that were near can switch to short — or vice versa. A single such flip
   is ±3 bytes.
2. Register allocation differences. Registers r8–r15 require a 1-byte REX prefix; rax–rdi don't. Different live-range
   pressure between the two instantiations can shift one variable from rdi to r12, which silently grows every instruction
   touching it.
3. Basic-block reordering. The JIT orders blocks by edge weight / heuristics. Different inlining decisions in callees
   can change perceived hotness and reorder blocks, which changes which edges are fall-through vs. branch.
4. Alignment padding. The JIT inserts NOPs ahead of loop heads (often 16-byte alignment). When earlier code shrinks,
   the loop head's natural address shifts, so the padding changes.
5. Profile counter placement. The tier-1 JIT inserts CORINFO_HELP_COUNTPROFILE32 calls; placement isn't bitwise
   identical across instantiations.

End-to-end latency: main vs this branch (NoEventPolicy)

ConcurrentLfu.GetOrAdd hot path (key already present), capacity 9, 1 stripe. main's pre-events ConcurrentLfu was built as BitFaster.Caching.MainBaseline.dll and referenced via extern alias so both implementations coexist in the same
benchmark process.

The Foreground\NullScheduler rows are the cleanest signal — it skips all scheduler-side interference. The BackgroundThread and ThreadPool rows carry larger variance from scheduler timing and inter-thread coordination, not from code-path differences inside the cache.

Before (main)

After (8d4ee12)

Not clear why threadpool became so fast as a one off, does not repro.

Multiple runs (events and no events are the same code):